A P2P system has an architecture in which each node (e.g., workstation, computer) has equal or similar capabilities and responsibilities. The P2P system differs from a client/server architecture where some nodes are dedicated to serving other nodes. In the past, P2P systems have been applied to basic Internet routing and to applications such as Usenet News which is a worldwide bulletin board system that is accessed by millions of people daily through the Internet or through many online services. More recently, P2P systems have been applied to resource location applications by utilizing so-called overlay networks such as Gnutella, Freenet, Pastry, P-Grid, or DKS, on top of a physical network. Basically, all of these overlay networks provide a resource location service and on top of the physical network where different distributed application services can be realized, such as data management (search, insert, update, etc.). If desired, these distributed application services could directly use the physical network for managing their resources. However, using an overlay network has the advantage of supporting application specific identifier space and semantic routing, and offers the possibility to provide additional, generic services like supporting network maintenance, authentication, trust, etc., all of which would be very hard to integrate into and support at the physical network layer. Thus, the introduction of overlay networks (which is discussed in detail next) and self-management at the service-level were very important innovations to P2P systems.
Each overlay network has a group of nodes P that provide access to a set of resources R by mapping P and R to an application-specific identifier space I utilizing two functions FP: P→I and FR: R→I. These mappings establish an association of resources R to nodes P using a closeness metric on the application-specific identifier space I. To enable access from any node P to any resource R a logical network is built, i.e., a graph is embedded into the application-specific identifier space I. Basically, each specific overlay network can be characterized by the decisions made on the following six key design aspects:                1. Choice of an identifier space I.        2. Mapping of resources R and nodes P to the identifier space I.        3. Management of the identifier space I by the nodes P.        4. Graph embedding (structure of the logical network).        5. Routing strategy.        6. Maintenance strategy.        
In making these design decisions, one often attempts to address one or more of the following characteristics that can be associated with an overlay network:
Efficiency: The routing should preferably incur a minimum number of overlay hops (with a minimum physical distance) and the bandwidth (including the number and sizes of the messages) for constructing and maintaining the overlay network should preferably be kept minimal.
Scalability: The concept of scalability includes many aspects such as, for example, numerical scalability, i.e., where there can be very large numbers of participating nodes without significant performance degradation.
Self-organization: The lack of centralized control and frequent changes in the set of participating nodes requires a certain degree of self-organization, i.e., in the presence of churn the overlay network should preferably be adapted to self-reconfigure itself towards stable configurations. This theoretical approach is a stabilization requirement since external intervention typically is not possible.
Fault-tolerance: Participating nodes and network links can fail at any time but all of the resources should preferably still be accessible from all nodes. This is typically achieved by some form of redundancy. Basically, fault-tolerance implies that even if parts of the overlay network cease operation, then the overlay network should preferably still be able provide an acceptable service.
Cooperation: The overlay network depends on the cooperation of the nodes, i.e., nodes have to trust that the nodes they interact with will behave properly in respect to routing, exchange of index information, quality of service, etc. . . . .
To date, a wide range of algorithms, structures, and architectures for overlay networks have been proposed, integrating knowledge from many different communities, such as networking, distributed systems, databases, graph theory, agent systems, complex systems, etc. . . . . A DHT overlay network is one such overlay network which has been proposed to be used as a generic building block for large-scale distributed applications. The following documents discuss the traditional DHT overlay network in great detail (the contents of which are incorporated by reference herein):                Ion Stoicay et al., “Chord: A Scalable Peer-to-peer Lookup Protocol for Internet Applications”, SIGCOMM'01, Aug. 27-31, 2001, San Diego, Calif., USA.        D. Malkhi et al., “Viceroy: A scalable and dynamic emulation of the butterfly,” Proc. 21st ACM Symposium on Principles of Distributed Computing, 2002.        P. Maymounkov et al., “Kademlia: A peer-to-peer information system based on the xor metric,” Proceedings of International Peer-to-Peer Symposium, 2002.        S. Ratnasamy et al., “A scalable content addressable network,” in Proceedings of ACM SIGCOMM 2001, 2001.        Rowstron et al., “Pastry: Scalable, decentralized object location, and routing for large-scale peer-to-peer systems,” Lecture Notes in Computer Science, vol. 2218, pp. 329-350, 2001.        Karger, D. et al. “Consistent hashing and random trees: Distributed caching protocols for relieving hot spots on the World Wide Web” Proceedings of the 29th Annual ACM Symposium on Theory of Computing (El Paso, Tex., May 1997), pp. 654-663.Because, the set of participating nodes in the traditional DHT overlay network is assumed to be very large and dynamic, each of the node's views of the current set of participants are not synchronized since it would be too costly. Instead, the traditional DHT overlay network's approach is to simply form a routing overlay on which requests for data entries often require more than one network hop before reaching the particular nodes that are responsible for managing the requested data entries. This problem with the traditional DHT scheme is discussed below in greater detail with respect to FIGS. 1A-1B.        
Referring to FIG. 1A (PRIOR ART), there is shown a diagram of an exemplary P2P system 100 which has ten traditional DHT nodes N1, N8 . . . N56. The DHT nodes N1, N8 . . . N56 each have a distinct DHT hash table 102 that is used to enable the following: (1) queries for a given identifier are passed around the given topology (a circle in this case) via successor pointers until they encounter a pair of nodes that straddle the desired identifier; and (2) the second in the pair of nodes is the node that the query maps to find the desired data entry. In the present example, the DHT node N8 has DHT hash table 102 which stores references to, addresses or identifiers of various DHT nodes N14, N21, N32 and N42 (see column 104) that it would query for a limited number of ranges of key values 8+20, 8+21, 8+22 . . . 8+25 (see column 106). As can be seen, DHT node N8 has a DHT hash table 102 which stores references to, addresses or identifiers of only a small number of the DHT nodes N14, N21, N32 and N42, and knows more about DHT node N14 which is close to DHT node 8 on the identifier circle than about DHT nodes N21, N32 and N42 farther away. Second, it can be seen, that DHT node N8 does not have a DHT hash table 102 that contains enough information to determine the exact location of every possible key k (note: these particular features are also true with DHT nodes N1, N14 . . . N56 and their respective DHT hash tables).
Referring to FIG. 1B (PRIOR ART), there is shown another diagram of the exemplary P2P system 100 in which DHT node N8 has received a query 108 (lookup key 54) and uses the DHT hash table 102 to determine that the query 108 needs to be forwarded to another DHT node N42 so it gets closer to its final destination which is DHT node 56. In this example, assume that DHT node N8 wants to find the successor of key 54. Since, the largest entry in the DHT hash table 102 of DHT node N8 that precedes key 54 is DHT node N42, then DHT node 8 will ask DHT node N42 to resolve the query 108 (see numeral “1”). In turn, DHT node N42 will determine the largest entry in its DHT hash table that precedes key 54, i.e., DHT node N51, DHT node N42 will ask DHT node 51 to resolve the query 108 (see numeral “2”). Next, DHT node N51 will discover after checking its DHT hash table that its own successor, DHT node N56, succeeds key 54, and thus will ask DHT node N56 to resolve the query 108 (see numeral “3”). Finally, DHT node N56 will return it's address 110 back to the originating DHT node N8 (see number “4”). As can be seen, this DHT request routing involved several network hops from DHT node N8 to DHT nodes N42, N51 and N56.
The several network hops it can take to resolve a query 108 is a fundamental problem with the traditional DHT overlay network 100. In fact, in the traditional DHT overlay network 100 which is operating in a steady state mode, each DHT node typically maintains information about only O(log N) other DHT nodes, and resolves all lookups via O(log N) messages/hops to other DHT nodes. Thus, when one tries to build faster, stronger, and more reliable DHT overlay network, which is more suited to be used in a trusted environment like the telecommunication environment, then there is a problem with the large number of network hops associated with the classical approach. This large number of network hops can bring the performance down in the telecommunication environment which typically has a limited number of telecommunication nodes (hardware and software) working in a network environment which is private, secure, trusted, and in which the nodes are near to each other network-wise, i.e. with very low latency. Accordingly, there is a need to address this problem and other problems which are associated with the classical DHT overlay network 100 when implementing DHT in a trusted environment like for instance the telecommunication environment. This need and other needs are satisfied by the present invention.